SIMULATION METHOD AND EMULATION METHOD 



BACKGROUND OF THE INVENTION 

Field of the Invention 

5 The present invention relates to a simulation method and an emulation 

method and, more specifically, to a method for verifying a hardware description language 
in a design process of a semiconductor device. 

Description of the Prior Art 

10 In recent years, improvement of efficiency in designing of a semiconductor 

device has been considered as a more significant factor along with an increase in the scale 
of semiconductor devices. With such a background, a semiconductor device is designed 
using a hardware description language that expresses the operation of the semiconductor 
device as does a programming language. 

15 In the design of a semiconductor device using hardware description, it is 

necessary to verify whether or not a designed hardware description operates according to 
the specifications of the semiconductor device. A general structure of a conventional 
simulation apparatus for performing the verification is shown in FIG. 32. This apparatus 
includes a simulation execution section 3 and an executed-row counting section 5. The 

20 simulation execution section 3 simulates a RTL description 1 based on a test vector 2. The 
RTL description 1 describes a function of a semiconductor device in a hardware 
description language. RTL is an abbreviation for a resister transfer level, which is a level 
of abstraction of description. The test vector 2 is created by a designer of the 
semiconductor device in accordance with the specifications of the semiconductor device. 

25 The designer verifies whether or not the RTL description 1 is appropriately designed while 
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checking in a one-by-one manner whether or not simulation results 4 of the simulation 
performed by the simulation execution section 3 are identical to the specifications. The 
executed-row counting section 5 outputs a coverage result 6, which is obtained by counting 
and observing executed rows of the RTL description 1 in a one-by-one manner during the 
5 simulation execution process in order to measure the verification coverage of the test 
vector 2. The designer specifies unexecuted rows of the RTL description 1 from the 
coverage result 6 and adds a test vector 2 for re-simulation such that the unexecuted rows 
are executed, whereby a high-quality semiconductor device with no omission of 
verification is designed. 

10 In the simulation apparatus of FIG. 32, the simulation execution section 3 

performs sequential processing and, therefore, a row which is not functionally executed is 
instantaneously executed in the simulation. As a result, an error count occurs in the 
executed-row counting section 5, and the coverage result 6 output from the section 5 has an 
unduly high coverage. This problem is described with reference to an RTL description 

15 example of FIG. 3A and a test vector description example of FIG. 3B. 

FIGS. 3A and 3B are examples where Verilog-HDL is used as a hardware 
description language. The numbers vertically aligned at the left side denote the row 
numbers of the descriptions. In FIG. 3A, the "always" sentences at the 100th and 113th 
rows are syntaxes that are executed every time a defined signal changes. Specifically, 

20 every time any of "a", "b", and "c" at the 100th row changes, the 101st through 1 10th rows 
are executed. Such a group of descriptions which perform a series of processes in response 
to a signal change is herein defined as a description block. The example of FIG. 3A 
includes two description blocks, i.e., the block of 100th through 1 1 1th rows and the block 
of 1 1 3th through 1 1 5th rows. 

25 At time 0, the 201st row of FIG. 3B is executed to substitute "a" and "b" 
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with 0 (zero). According to the sequential processing principle, the 100th row and 113th 
row are then evaluated in response to the change of "a" and "b". Herein, consider a case 
where execution is started with the 100th row. In this case, the value of "c" is indefinite 
while a=0 and b=0. Thus, "out" is not replaced by any particular number, and the process 
5 proceeds to the 113th row, at which "c" is replaced by 1 (c=l). Then, in response to the 
change of "c", the 100th row is evaluated again. According to the "case" sentence at the 
101st row, the 103rd row of {a, b, c}={0, 0, 1} is executed, and "out" is replaced by 0. 
Then, at time 100, the 202nd row of FIG. 3B is executed, whereby "a" is replaced by 1 
(a=l). Then, in response to the change of "a", the 100th row of FIG. 3A is evaluated. The 

10 107th row of {a, b, c}={1, 0, 1} is executed according to the "case" sentence of the 101st 
row, and "out" is replaced by 1. Then, the process proceeds to the 1 13th row, at which "c" 
is replaced by 0 (c=0). Then, in response to the change of "c", the 100th row is evaluated 
again. The 106th row of (a, b, c}={1, 0, 0} is executed according to the "case" sentence of 
the 101st row, and "out" is replaced by 0. The coverage result of the above process is 

15 shown in FIG. 33. FIG. 33 shows the number of times of execution for each row at the left 
side of the RTL description example of FIG. 3A. In the case where the count is 
incremented for every sequential execution as described above, the 107th row which is not 
functionally executed is executed in the simulation and, therefore, a resultant coverage 
result has an unduly high coverage. 

20 

SUMMARY OF THE INVENTION 

An objective of the present invention is to provide a simulation method 
wherein an error count in coverage measurement in a simulation of a hardware description 
language is prevented. 

25 The first simulation method of the present invention comprises the steps of: 



3 



recording executed rows for each description block; and if the same description block is 
performed at the same time, deleting a previous executed-row history of the description 
block performed at the time. 

According to the above simulation method, an error count in coverage 
5 measurement in a simulation of a hardware description language is prevented. 

The second simulation method of the present invention comprises the steps 
of: dividing a hardware description into description blocks; analyzing, for each description 
block, correspondence information that represents correspondence between combinations 
of input signals to the description block and executed rows; in a simulation execution 

10 process, tracing input signals to each description block; and analyzing the executed rows 
according to an analysis result of the correspondence information that represents the 
correspondence between combinations of input signals to the description block and 
executed rows and a trace result of the input signals to the description block. 

According to the above simulation method, the overhead for coverage 

15 measurement in a simulation of a hardware description language is reduced. 

The third simulation method of the present invention comprises the steps of: 
dividing a hardware description into description blocks; analyzing, for each description 
block, correspondence information that represents correspondence between combinations 
of input signals to the description block and executed rows; in a simulation execution 

20 process, tracing input signals to each description block every unit time; and analyzing the 
executed rows according to an analysis result of the correspondence information that 
represents the correspondence between combinations of input signals to the description 
block and executed rows and a trace result of the input signals to the description block, the 
trace result being obtained every unit time. 

25 According to the above simulation method, an error count in coverage 
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measurement in a simulation of a hardware description language is prevented while the 
overhead is reduced. 

The fourth simulation method of the present invention comprises the steps 
of: dividing a hardware description into description blocks; analyzing, for each description 
5 block, correspondence information that represents correspondence between combinations 
of input signals to the description block and executed rows; in a simulation execution 
process, tracing input signals to each description block every cycle; and analyzing the 
executed rows according to an analysis result of the correspondence information that 
represents the correspondence between combinations of input signals to the description 

10 block and executed rows and a trace result of the input signals to the description block, the 
trace result being obtained every cycle. 

According to the above simulation method, in the case where a 
semiconductor device to be designed is based on the perfectly synchronous design, an error 
count in coverage measurement in a simulation of a hardware description language is 

15 prevented while the overhead is reduced. 

The first emulation method of the present invention comprises the steps of: 
dividing a hardware description into description blocks; extracting, for each description 
block, signals used in a hardware emulation process which correspond to input signals to 
the description block; analyzing correspondence information that represents 

20 correspondence between combinations of the signals used in hardware emulation process 
which correspond to input signals to the description block and executed rows; in an 
emulation execution process, tracing the signals used in hardware emulation process which 
correspond to input signals to each description block; and analyzing executed rows 
according to the correspondence information that represents the correspondence between 

25 the combinations of the signals used in the hardware emulation process which correspond 
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to the input signals to the description block and the executed rows and a result of the 
tracing of the signals used in the hardware emulation process which correspond to the input 
signals to the description block. 

According to the above emulation method, coverage measurement is 
5 achieved in a hardware emulation of a hardware description language. 

The second emulation method of the present invention comprises the steps 
of: dividing a hardware description into logic cones; extracting, for each logic cone, signals 
used in a hardware emulation process which correspond to input signals to the logic cone; 
analyzing correspondence information that represents correspondence between 

10 combinations of the signals used in the hardware emulation process which correspond to 
input signals to the logic cone and executed rows; in an emulation execution process, 
tracing the signals used in the hardware emulation process which correspond to input 
signals to each logic cone; and analyzing executed rows according to the correspondence 
information that represents the correspondence between the combinations of the signals 

15 used in the hardware emulation process which correspond to the input signals to the logic 
cone and the executed rows and a result of the tracing of the signals used in the hardware 
emulation process which correspond to the input signals to the logic cone. 

According to the above emulation method, coverage measurement is 
achieved in a hardware emulation of a hardware description language under the condition 

20 that an optimization process of circuitry is performed. 

The fifth simulation method of the present invention comprises the steps of: 
dividing a hardware description into description blocks; analyzing, for each description 
block, input conditions for executing respective rows included in the description block; 
analyzing correspondence information that represents correspondence between the input 

25 conditions and executed rows; in a simulation execution process, tracing input signals to 



each description block; and analyzing executed rows based on the correspondence 
information that represents the correspondence between the input conditions and the 
executed rows and a tracing result of the input signal to the description block. 

According to the above simulation method, in a simulation of a hardware . 
5 description language, coverage measurement can be performed on a description block 
which receives many input signals. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a block diagram showing a structure of a simulation apparatus 
10 according to embodiment 1. 

FIG. 2 is a flowchart of a process performed in an executed-row counting 
section of FIG. 1. 

FIG. 3A shows an example of a RTL description. FIG. 3B shows an 
example of a test vector. 
1 5 FIG. 4 shows a coverage result. 

FIG. 5 is a block diagram showing a structure of a simulation apparatus 
according to embodiment 2. 

FIG. 6 is a flowchart showing a process performed in a block input- 
executed row correspondence table creating section of FIG. 5. 
20 FIG. 7 shows an example of a block input-executed row correspondence 

table. 

FIG. 8 is a flowchart showing a process performed in an executed-row 
counting section of FIG. 5. 

FIG. 9 is a block diagram showing a structure of a simulation apparatus 
25 according to embodiment 3. 
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FIG. 10 is a flowchart showing a process performed in an executed-row 
counting section of FIG. 9. 

FIG. 11 is a block diagram showing a structure of a simulation apparatus 
according to embodiment 4. 
5 FIG. 12 is a flowchart showing a process performed in an executed-row 

counting section of FIG. 11. 

FIG. 13 shows an example of a gate level netlist. 

FIG. 14 is a block diagram showing a structure of an emulation apparatus 
according to embodiment 5. 
10 FIG. 15 shows an example of RTL-Gate correspondence information. 

FIG. 16 is a flowchart showing an operation performed in a gate level block 
input-executed row correspondence table creating section of FIG. 14. 

FIG. 17 is an example of a gate level block input-executed row 
correspondence table. 

15 FIG. 18 is a flowchart showing an operation performed in an executed-row 

counting section of FIG. 14. 

FIG. 19 shows an example of a gate level netlist. 

FIG. 20 is a block diagram showing a structure of an emulation apparatus 
according to embodiment 6. 
20 FIG. 21 shows an example of logic cone RTL-Gate correspondence 

information. 

FIG. 22 is a flowchart showing an operation performed in a logic cone 
input-executed row correspondence table creating section of FIG. 20. 

FIG. 23 shows an example of a logic cone input-executed row 
25 correspondence table. 
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FIG. 24 is a flowchart showing an operation performed in an executed-row 
counting section of FIG. 20. 

FIG. 25 is a block diagram showing a structure of a simulation apparatus 
according to embodiment 7. 
5 FIG. 26 is a flowchart showing an operation performed in a condition- 

specific block input-executed row correspondence table creating section of FIG. 25. 

FIG. 27 shows an example of a RTL description. 

FIG. 28 shows an example of a condition-specific block input-executed row 
correspondence table. 

10 FIG. 29 is a flowchart showing an operation performed in an executed-row 

counting section of FIG. 25. 

FIG. 30 shows an example of a test vector. 
FIG. 31 shows a coverage result. 

FIG. 32 is a block diagram showing a structure of a conventional simulation 

15 apparatus. 

FIG. 33 shows a coverage result. 

DESCRIPTION OF THE PREFERRED EMBODIMENTS 

Hereinafter, embodiments of the present invention are described with 
20 reference to the drawings. It should be noted that identical or equivalent elements are 
denoted by the same reference numerals throughout the drawings, and descriptions thereof 
are not repeated. 

(Embodiment 1) 

25 FIG. 1 shows a structure of a simulation apparatus according to 



9 



embodiment 1 . The simulation apparatus includes a simulation execution section 3 and an 

executed-row counting section 10. 

The simulation execution section 3 simulates a RTL description 1 based on 

a test vector 2. The RTL description 1 describes a function of a semiconductor device in a 
5 hardware description language. RTL is an abbreviation for a resister transfer level, which 

is a level of abstraction of description. The test vector 2 is created by a designer of the 

semiconductor device in accordance with the specifications of the semiconductor device. 

The executed-row counting section 10 includes a unit time executed-row 

tracing section 11 and an executed-row compilation section 12. 
10 The unit time executed-row tracing section 11 receives executed-row 

information from the simulation execution section 3 and extracts executed rows for each 

description block every unit time. The unit time is the minimum time that can be 

designated by the designer. 

The executed-row compilation section 12 counts the number of times of 
1 5 execution for each row based on the executed-row information extracted from the unit time 

executed-row tracing section 11 and outputs a coverage result 6 after the simulation 

execution process is completed. 

Next, a process performed in the executed-row counting section 10 is 

described with reference to FIG. 2. 
20 At the same time with the start of the simulation execution process 

performed by the simulation execution section 3, an executed row counting process is 

started (ST 101). After the counting is started, the executed row counting loop (ST 102 to 

ST111) is repeated until the end of the simulation execution process, while the unit time 

executed-row trace loop (ST103 to ST108) is repeated till the simulation time is updated. 
25 At stepST104, current execution information is received from the 
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simulation execution section 3, and it is checked whether or not the row executed by the 
simulator has been changed. If not, the unit time executed-row trace loop which starts 
from step ST103 is performed till the simulation time is updated. If the executed row has 
been changed at step ST 104, it is checked whether or not the current executed row is the 
5 first row of the description block (ST105). If it is the first row of the description block, a 
count table for the description block that includes the current executed row is cleared 
(ST 106). The count table is provided for storing an execution history of each description 
block every unit time. Then, the current executed row is registered in the count table 
(ST107). If it is not the first block at ST105, the current executed row is registered in the 

10 count table without clearing the count table (ST 107). Then, the unit time executed-row 
trace loop that starts from step ST103 is performed again till the simulation time is 
updated. The process of step ST103 to step ST108 is performed in the unit time executed- 
row tracing section 11. 

When the simulation time is updated, executed-row summation tables for all 

15 of the executed rows registered in the count table are each incremented by 1 (ST109). This 
processing is performed in the executed-row compilation section 12. The executed-row 
summation table is provided to each row for storing the number of times of execution of 
the row. Then, the count table is cleared at stepSTHO. The process returns to the 
executed-row counting loop that starts from stepST102 to repeat the executed-row 

20 counting process till the simulation execution process is completed. 

FIG. 4 shows a coverage result which is obtained when the executed-row 
counting process is performed on the RTL description 1 shown in FIG. 3A and the test 
vector 2 shown in FIG. 3B. 

As described above, according to embodiment 1, only the executed row 

25 history of the row which has been functionally executed every unit time is extracted by the 
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unit time executed-row tracing section 11. Thus, the correct coverage result 6 which 
includes no error count can be obtained. 

(Embodiment 2) 

5 In the conventional simulation apparatus shown in FIG. 32, the process of 

tracing rows executed in a simulation is performed on every executed row on an executed- 
row by executed-row basis. Thus, an overhead is caused in the simulation execution 
process every time the executed row is updated, whereby the simulation speed is 
decreased. An objective of embodiment 2 is to reduce the overhead for the coverage 
10 measurement in the simulation of a hardware description language. 

FIG. 5 shows a structure of a simulation apparatus according to 
embodiment 2. This simulation apparatus includes a simulation execution section 3, a 
block input-executed row correspondence table creating section 20 and an executed-row 
counting section 21. 

15 The block input-executed row correspondence table creating section 20 

divides the RTL description 1 into description blocks and analyzes for each description 
block the correspondence between the combinations of input signals to the block and the 
executed rows, thereby extracting correspondence information that represents the 
correspondence between the combinations of input signals to the block and the executed 

20 rows. 

The executed-row counting section 21 includes a block input tracing 
section 22, an executed-row analyzing section 23 and an executed-row compilation 
section 12. 

The block input tracing section 22 receives input signal information from 
25 the simulation execution section 3 every time any input signal to a description block 
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obtained in the block input-executed row correspondence table creating section 20 is 
changed. 

The executed-row analyzing section 23 extracts an executed row based on 
the input signal information received by the block input tracing section 22 and the 
5 correspondence information that represents the correspondence between the combinations 
of input signals to the block and the executed rows which has been extracted by the block 
input-executed row correspondence table creating section 20. 

The executed-row compilation section 12 counts the number of times of 
execution for each row based on the executed-row information extracted by the executed- 
10 row analyzing section 23 and outputs the coverage result 6 after the simulation execution 
process is completed. 

Next, a process performed in the block input-executed row correspondence 
table creating section 20 is described with reference to FIG. 6. 

In the first place, the simulation apparatus reads the RTL description 1 
15 (ST201). Herein, it is assumed that the simulation apparatus reads the RTL description 
shown in FIG. 3A. 

Then, the read RTL description 1 is divided into description blocks 
(ST202). Through this process, the read RTL description 1 is divided into the description 
block of the 100th to 1 10th rows and the description block of the 1 13th to 1 15th rows (see 
20 FIG. 3A). The process of a block-specific correspondence table creation loop of 
subsequent steps ST203 to ST209 is performed on all of the description blocks obtained at 
step ST202. 

Then, the input signals to a description block that is to be processed (target 
description block) are extracted (ST204). When the target description block is the 
25 description block of the 1 13th to 1 15th rows, the input signals to the block are "a", "b" and 



"c" (see FIG. 3A). The process of a block input pattern generation loop of subsequent 
steps ST205 to ST208 is performed on all of the combinations of input signals to the block 
which are extracted at step ST204. In the case of the description block of the 113th to 
115th rows, the process of the block input pattern generation loop is performed on 
5 8 combinations of {a, b, c}={0, 0 5 0} to {1, 1, 1}. 

Then, executed rows of the target description block for a target combination 
pattern are analyzed (ST206). In the case where the target pattern is {a, b, c}={0, 0, 0}, 
the executed rows are the 100th, 101st and 102nd rows (see FIG. 3A). 

Then, the correspondence between the input signals to the block and the 
10 executed rows, which has been obtained at step ST206, is added to the block input- 
executed row correspondence table (ST207). 

Then, the combination of the block input signals is changed, and the process 
returns to the loop of steps ST205 to ST208. After the process has been done for all of the 
combinations, the process proceeds to a next description block to perform the loop of 
15 steps ST203 to ST209. 

FIG. 7 shows a block input-executed row correspondence table obtained by 
performing the above process on the RTL description shown in FIG. 3A. 

Then, the executed-row counting process performed in the executed-row 
counting section 21 is described with reference to FIG. 8. 
20 The executed-row counting process is started at the same time with the start 

of the simulation execution process performed by the simulation execution section 3 
(ST250). 

Then, the input signals to each of the blocks obtained in the block input- 
executed row correspondence table creating section 20 are registered as a trace point used 
25 in the simulation execution process (ST251). 
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The executed-row counting loop of subsequent steps ST252 to ST256 is 
continued till the simulation execution process is completed. 

Then, it is checked whether or not the trace point has been changed in the 
simulation execution process (ST253). The above-described process up to step ST253 is 
5 performed in the block input tracing section 22. 

If the trace point has not been changed at step ST253, the process directly 
returns to the loop that starts from step ST252. If the trace point has been changed, the 
executed rows are extracted according to the value of the trace point and the block input- 
executed row correspondence table obtained from the block input-executed row 
10 correspondence table creating section 20 (ST254). This process is executed in the 
executed-row analyzing section 23. 

Then, the executed-row summation tables for all of the executed rows 
extracted at step ST254 are each incremented by 1 (ST255). This process is performed in 
the executed-row compilation section 12. Then, the process returns to the executed-row 
15 counting loop that starts from step ST252 to perform the executed-row counting process 
till the simulation execution process is completed. 

The coverage result 6 obtained by performing the above-described 
executed-row counting process on the RTL description 1 shown in FIG. 3A and the test 
vector 2 shown in FIG. 3B is the same as the conventional coverage result shown in 
20 FIG. 33. However, in embodiment 2, only the input signals to the description block are 
traced by the block input tracing section 22, whereas in the conventional simulation 
apparatus shown in FIG. 32 the process of tracing rows executed in a simulation is 
performed on every executed row on an executed-row by executed-row basis, whereby an 
overhead is caused in the simulation execution process every time the executed row is 
25 updated and, accordingly, the simulation speed is decreased. Thus, the structure of 
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embodiment 2 overcomes such a problem of the conventional simulation apparatus. That 
is, the overhead for the coverage measurement in the simulation of a hardware description 
language is reduced. 



5 (Embodiment 3) 

In the conventional simulation apparatus shown in FIG. 32, the simulation 
execution section 3 performs sequential processing and, therefore, a row which is not 
functionally executed is instantaneously executed in the simulation. As a result, an error 
count occurs in the executed-row counting section 5, and there is a possibility that the 
1 0 coverage result 6 output from the section 5 has an unduly high coverage. Moreover, the 
process of tracing rows executed in the simulation is performed on every executed row on 
an executed-row by executed-row basis. Thus, an overhead is caused in the simulation 
execution process every time the executed row is updated and, accordingly, the simulation 
speed is decreased. An objective of embodiment 3 is to prevent an error count in the 
15 coverage measurement in the simulation of a hardware description language while 
reducing the overhead. 

FIG. 9 shows a structure of a simulation apparatus according to 
embodiment3. This simulation apparatus includes a simulation execution section 3, a 
block input-executed row correspondence table creating section 20 and an executed-row 
20 counting section 30. 

The executed-row counting section 30 includes a unit time block input 
tracing section 31, an executed-row analyzing section 23 and an executed-row compilation 
section 12. 

The unit time block input tracing section 31 receives from the simulation 
25 execution section 3 a change in the input signals to a description block which is obtained in 
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the block input-executed row correspondence table creating section 20. 

The executed-row analyzing section 23 extracts executed rows according to 
the information about the input signal received by the unit time block input tracing 
section 31 and the correspondence information that represents the correspondence between 
5 the combinations of input signals to the block and the executed rows which has been 
extracted by the block input-executed row correspondence table creating section 20. 

Next, a process performed in the executed-row counting section 30 is 
described with reference to FIG. 10. 

At the same time with the start of a simulation execution process performed 
10 by the simulation execution section 3, an executed row counting process is started 
(ST300). 

Then, the input signals to each of the blocks obtained in the block input- 
executed row correspondence table creating section 20 are registered as a trace point used 
in the simulation execution process (ST301). 
15 The executed-row counting loop of subsequent steps ST3 02 to ST310 is 

continued till the simulation execution process is completed. The unit time tracing loop of 
steps ST303 to ST306 is repeated till the simulation time is updated. 

Then, it is checked whether or not the trace point has been changed in the 
simulation execution process (ST304). If not, the process returns to the loop that starts 
20 from step ST303. If the trace point has been changed, a unit time change table for the 
description block that includes the changed trace point is updated, and the process returns 
to the loop that starts from step ST303 (ST305). The unit time change table is provided for 
storing the values of input signals to each description block every unit time. 

When the simulation time is updated, it is checked whether or not the unit 
25 time change table of each description block has been updated (ST307). The above- 



described process up to step ST307 is performed in the unit time block input tracing 
section 31. 

If the unit time change table has not been updated at step ST307, the 
process returns to the loop that starts from step ST302. If the unit time change table has 
5 been updated, executed rows are according to the value of the updated unit time change 
table and the block input-executed row correspondence table obtained from the block 
input-executed row correspondence table creating section 20 (ST308). This process is 
performed in the executed-row analyzing section 23. 

Then, the executed-row summation tables for all of the executed rows 
10 extracted at step ST308 are each incremented by 1 (ST309). This process is performed in 
the executed-row compilation section 12. Then, the process returns to the executed-row 
counting loop that starts from step ST302 to perform the executed-row counting process 
till the simulation execution process is completed. 

A coverage result obtained by performing the above-described executed- 
15 row counting process on the RTL 1 description shown in FIG. 3A and the test vector 2 
shown in FIG. 3B is the same as the coverage result 6 shown in FIG. 4. 

As described above, in embodiment 3, only the information about the input 
signals to the description block which are functionally changed every unit time is extracted 
by the unit time block input tracing section 31. Therefore, the correct coverage result 6 
20 which includes no error count can be obtained. Moreover, according to embodiment 3, 
only the input signals to the description block are traced by the unit time block input 
tracing section 31. Such a feature avoids the problems of the conventional simulation 
apparatus that an overhead is caused in the simulation execution process every time the 
executed row is updated and, accordingly, the simulation speed is decreased. That is, the 
25 overhead for the coverage measurement in the simulation of a hardware description 



language is reduced. 

(Embodiment 4) 

In the conventional simulation apparatus shown in FIG. 32, the simulation 
5 execution section 3 performs sequential processing and, therefore, a row which is not 
functionally executed is instantaneously executed in the simulation. As a result, an error 
count occurs in the executed-row counting section 5, and there is a possibility that the 
coverage result 6 output from the section 5 has an unduly high coverage. Moreover, the 
process of tracing rows executed in the simulation is performed on every executed row on 

10 an executed-row by executed-row basis. Thus, an overhead is caused in the simulation 
execution process every time the executed row is updated and, accordingly, the simulation 
speed is decreased. An objective of embodiment 4 is to prevent an error count in the 
coverage measurement in the simulation of a hardware description language while 
reducing the overhead, in the case where a semiconductor device to be designed is based 

1 5 on the perfectly synchronous design. 

FIG. 11 shows a structure of a simulation apparatus according to 
embodiment 4. This simulation apparatus includes a simulation execution section 3, a 
block input-executed row correspondence table creating section 20 and an executed-row 
counting section 40. 

20 The executed-row counting section 40 includes a cycle-based block input 

tracing section 41, an executed-row analyzing section 23 and an executed-row compilation 
section 12. 

The cycle-based block input tracing section 41 receives from the simulation 
execution section 3 a change in the input signals to a description block which is obtained in 
25 the block input-executed row correspondence table creating section 20 as input signal 

19 



information every cycle. 

The executed-row analyzing section 23 extracts executed rows according to 
the input signal information received by the cycle-based block input tracing section 41 and 
the correspondence information that represents the correspondence between the 
5 combinations of input signals to the block and the executed rows which has been extracted 
by the block input-executed row correspondence table creating section 20. 

Next, a process performed in the executed-row counting section 40 is 
described with reference to FIG. 12. 

At the same time with the start of a simulation execution process performed 
10 by the simulation execution section 3, an executed row counting process is started 
(ST400). 

Then, the input signals to each of the blocks obtained in the block input- 
executed row correspondence table creating section 20 are registered as a trace point used 
in the simulation execution process (ST401). 
15 The executed-row counting loop of subsequent steps ST402 to ST410 is 

continued till the simulation execution process is completed. The unit time tracing loop of 
steps ST403 to ST406 is repeated till the simulation time is updated to the next cycle. 

Then, it is checked whether or not the trace point has been changed in the 
simulation execution process (ST404). If not, the process returns to the loop that starts 
20 from step ST403. If the trace point has been changed, a cycle-based change table for the 
description block that includes the changed trace point is updated, and the process returns 
to the loop that starts from step ST403 (ST405). The cycle-based change table is provided 
for storing the values of input signals to each description block every unit time. 

When the simulation time is updated to the next cycle, it is checked whether 
25 or not the cycle-based change table of each description block has been updated (ST407). 
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The above-described process up to step ST407 is performed in the cycle-based block input 
tracing section 41. 

If the cycle-based change table has not been updated at step ST407, the 
process returns to the loop that starts from step ST402. If the cycle-based change table has 
5 been updated, executed rows are extracted according to the value of the updated cycle- 
based change table and the block input-executed row correspondence table obtained from 
the block input-executed row correspondence table creating section 20 (ST408). This 
process is performed in the executed-row analyzing section 23. 

Then, the executed-row summation tables for all of the executed rows 
10 extracted at step ST408 are each incremented by 1 (ST409). This process is performed in 
the executed-row compilation section 12. Then, the process returns to the executed-row 
counting loop that starts from step ST402 to perform the executed-row counting process 
till the simulation execution process is completed. 

A coverage result obtained by performing the above-described executed- 
1 5 row counting process on the RTL description 1 shown in FIG. 3A and the test vector 2 
shown in FIG. 3B is the same as the coverage result 6 shown in FIG. 4. 

As described above, in embodiment 4, the cycle-based block input tracing 
section 41 extracts only the information about the input signals to the description block 
which are functionally changed every cycle. Therefore, the correct coverage result 6 
20 which includes no error count can be obtained. Moreover, according to embodiment 4, 
only the input signals to the description block are traced by the cycle-based block input 
tracing section 41. Such a feature avoids the problems of the conventional simulation 
apparatus that an overhead is caused in the simulation execution process every time the 
executed row is updated and, accordingly, the simulation speed is decreased. Furthermore, 
25 the executed-row analyzing section 23 and the executed-row compilation section 12 
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operate only on a cycle basis. Thus, the process speed is further improved as compared 
with the simulation method of embodiment 3. 



(Embodiment 5) 

5 In the designing of a semiconductor device using a hardware description, a 

hardware emulator is sometimes used in place of a software-based simulator in order to 
verify that a designed hardware description operates as per the specifications of the 
semiconductor device. The hardware emulator can perform verification 10,000 or more 
times faster than a software-based simulator can. Next, a general structure of such a 

10 hardware emulator is described. In the hardware emulator, a RTL description to be 
verified is converted to gate level data through a logic construction process, and the gate 
level data is replaced with actual hardware, such as a FPGA, or the like, whereby the 
operation of the RTL description is emulated at high speed. For example, the RTL 
description shown in FIG. 3A is replaced with a gate level netlist of FIG. 13. In the gate 

15 level netlist of FIG. 13, II through 15 are instance names which are inherently assigned to 
respective circuit elements; Wl through W7 are names which are inherently assigned to 
nodes used for connecting the circuit elements. However, the emulation process does not 
include the concept of "executing a row" and therefore cannot measure the coverage. 

An objective of embodiment 5 is to achieve coverage measurement in a 

20 hardware emulation of a hardware description language. 

FIG. 14 shows a structure of an emulation apparatus according to 
embodiments. This emulation apparatus includes a logical synthesis section 51, an 
emulation execution section 54, a gate level block input-executed row correspondence 
table creating section 55 and an executed-row counting section 56. 

25 The logical synthesis section 51 converts a RTL description 1 to a gate level 
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netlist 52 in order to replace the RTL description 1 with hardware. In the case of the RTL 
description shown in FIG. 3A, the RTL description is converted to the gate level netlist of 
FIG. 13. While converting the RTL description to the gate level netlist, the logical 
synthesis section 51 outputs RTL-Gate correspondence information 53 that represents a 
5 correspondence between the RTL description 1 and the gate level netlist 52. FIG. 15 
shows RTL-Gate correspondence information for the case of the RTL description shown in 
FIG. 3A. 

The emulation execution section 54 has a function equivalent to the 
simulation execution section 3 of embodiments 1-4. 

10 The gate level block input-executed row correspondence table creating 

section 55 divides the RTL description 1 into description blocks and analyzes the 
correspondence for each description block between the combinations of input signals to the 
block and the executed rows in the emulation execution section 54 using the RTL-Gate 
correspondence information 53, thereby extracting correspondence information that 

15 represents the correspondence between the combinations of input signals to the block and 
the executed rows in the emulation execution section 54. 

The executed-row counting section 56 includes a gate level block input 
tracing section 57, an executed-row analyzing section 23 and an executed-row compilation 
section 12. 

20 The gate level block input tracing section 57 receives from the emulation 

execution section 54 a change in the input signals to a description block, which is obtained 
in the gate level block input-executed row correspondence table creating section 55, in the 
emulation execution section 54. 

The executed-row analyzing section 23 extracts executed rows according to 

25 the input signal information received by the gate level block input tracing section 57 and 
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the correspondence information that represents the correspondence between the 
combinations of input signals to the block which are employed in the emulation execution 
section 54 and the executed rows which has been extracted by the gate level block input- 
executed row correspondence table creating section 55. 

The executed-row compilation section 12 counts the number of times of 
execution for each row based on the executed-row information extracted from the 
executed-row analyzing section 23 and outputs a coverage result 6 after the emulation 
execution process is completed. 

Next, a process performed in the gate level block input-executed row 
correspondence table creating section 55 is described with reference to FIG. 16. 

In the first place, the emulation apparatus reads the RTL description 1 
(ST501). Herein, it is assumed that the emulation apparatus reads the RTL description 
shown in FIG. 3A. 

Then, the gate level block input-executed row correspondence table creating 
section 55 reads the RTL-Gate correspondence information 53 (ST502). 

Then, the RTL description 1 read at step ST501 is divided into description 
blocks (ST503). Through this process, the RTL description 1 is divided into description 
blocks of the 100th to 1 10th rows and description blocks of the 113th to 1 15th rows (see 
FIG. 3A). The process of a block-specific correspondence table creation loop of 
subsequent steps ST504 to ST511 is performed on every description block obtained at 
step ST503. 

Then, input signals to a description block to be processed are extracted 
(ST505). When the description block to be processed is the description block of the 1 13th 
to 1 1 5th rows, the input signals to the block are "a", "b" and "c" (see FIG. 3A). 

Then, signals for use in the emulation execution section 54, which 
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correspond to the input signals to the block extracted at step ST505, are extracted (ST506). 
Hereinafter, the signals for use in the emulation execution section 54 which correspond to 
the input signals to the block are referred to as "gate level block inputs". The process of a 
block input pattern generation loop of subsequent steps ST507 to ST510 is performed on 
5 all of the combinations of input signals to the block extracted at step ST505. In the case of 
the description block of the 113th to 115th rows, the process of the block input pattern 
generation loop is performed on 8 combinations of {a, b, c}={Wl, W2, W4}={0, 0, 0} to 
{1,1,1} (see FIG. 3A and FIG. 15). 

Then, executed rows of a target description block for a target combination 
10 pattern are analyzed (ST508). In the case where the target pattern is {a, b, c}={Wl, W2, 
W4}={0, 0, 0}, the executed rows are the 100th, 101st and 102nd rows. 

Then, the correspondence between the input signals to the block (block 
inputs) and the executed rows, which has been obtained at step ST508, is added to the gate 
level block input-executed row correspondence table (ST509). 
15 Then, the combination of the block inputs is changed, and the process 

returns to the loop of steps ST507 to ST510. After all of the combinations have been 
processed, the process proceeds to a next description block, and the loop of steps ST504 to 
ST511 is performed. 

FIG. 17 shows a gate level block input-executed row correspondence table 
20 obtained by performing the above process on the RTL description shown in FIG. 3A. 

Next, a process performed in the executed-row counting section 56 is 
described with reference to FIG. 18. 

The executed-row counting process is started at the same time with the start 
of the emulation execution process performed by the emulation execution section 54 
25 (ST550). 
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Then, the gate level block inputs to each of the blocks obtained in the gate 
level block input-executed row correspondence table creating section 55 are registered as a 
trace point used in the emulation execution process (ST551). The executed-row counting 
loop of subsequent steps ST552 to ST556 is continued till the emulation execution process 
5 is completed. 

Then, it is checked whether or not the trace point has been changed in the 
emulation execution process (ST553). The above-described process up to step ST553 is 
performed in the gate level block input tracing section 57. 

If the trace point has not been changed at step ST553, the process returns to 
10 the loop that starts from step ST552. If the trace point has been changed, the executed 
rows are extracted according to the value of the changed trace point and the gate level 
block input-executed row correspondence table obtained from the gate level block input- 
executed row correspondence table creating section 55 (ST554). This process is executed 
in the executed-row analyzing section 23. 
15 Then, the executed-row summation tables for all of the executed rows 

extracted at step ST554 are each incremented by 1 (ST555). This process is performed in 
the executed-row compilation section 12. 

Hereinafter, the process returns to the executed-row counting loop that 
starts from step ST552 to repeat the executed-row counting process till the emulation 
20 execution process is completed. 

A coverage result obtained by performing the above-described executed- 
row counting process on the RTL description 1 shown in FIG. 3A and the test vector 2 
shown in FIG. 3B is the same as the coverage result 6 shown in FIG. 4. 

As described above, according to embodiment 5, the executed rows of the 
25 RTL description 1 are estimated based on the gate level block input-executed row 
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correspondence table obtained from the gate level block input-executed row 
correspondence table creating section 55 and the process of tracing signals corresponding 
to the block inputs of the emulation execution section 54. Thus, the coverage observation, 
which cannot be measured in the conventional emulation methods, is achieved. 
5 Furthermore, the emulation execution process is not a sequential process, whereas a 
software simulation process is sequential. Therefore, the correct coverage result 6 which 
has no error count is achieved in the emulation execution process. 

(Embodiment 6) 

10 In the emulation apparatus shown in FIG. 14, the logical synthesis 

section 51 converts the RTL description 1 to the gate level netlist 52. In this conversion 
process, optimization of the logic is performed in some cases in order to reduce the number 
of circuit elements used in the hardware. FIG. 19 shows a gate level netlist obtained when 
an optimization process is performed on the RTL description of FIG. 3 A. By this 

15 optimization process, the scale of circuitry corresponding to the emulation execution 
process is increased and, accordingly, the speed of the emulation process is increased. 
However, the gate level block inputs, which correspond to the input signals to the 
description block of the RTL description 1, are deleted through the optimization process 
and, as a result, the emulation method described in embodiment 5 becomes inapplicable. 

20 An objective of embodiment 6 is to achieve coverage measurement in a hardware 
emulation of a hardware description language under the condition that the optimization 
process of circuitry is performed. 

FIG. 20 shows a structure of an emulation apparatus according to 
embodiment 6. This emulation apparatus includes a logical synthesis section 51, an 

25 emulation execution section 54, a logic cone input-executed row correspondence table 
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creating section 61 and an executed-row counting section 62. 

When converting a RTL description 1 to a gate level netlist 52, the logical 
synthesis section 51 outputs signal information 60 of the RTL description which 
corresponds to input signals to the respective logic cones of the gate level netlist 52 (logic 
5 cone RTL-Gate correspondence information). Herein, "logic cone" is defined as below. 
For example, in a logic circuit consisting of memory elements, such as a flip-flop, or the 
like, and combinational circuits, a combinational circuit which affects input terminals of 
the respective memory elements or an output terminal of the logic circuit is referred to as a 
"logic cone". FIG. 21 shows logic cone RTL-Gate correspondence information 60 
10 obtained when a logical synthesis process is performed on the RTL description shown in 
FIG. 3A. 

The logic cone input-executed row correspondence table creating section 61 
divides the RTL description 1 among logic cones by using the logic cone RTL-Gate 
correspondence information 60 and extracts, for each logic cone, correspondence 
15 information that represents the correspondence between the combinations of logic cone 
input signals used in the emulation execution section 54 and the executed rows of the RTL 
description 1. 

The executed-row counting section 62 includes a logic cone input tracing 
section 63, an executed-row analyzing section 23 and an executed-row compilation 
20 section 12. 

The logic cone input tracing section 63 receives from the emulation 
execution section 54 information about a change in the logic cone inputs in the emulation 
execution section 54. 

The executed-row analyzing section 23 extracts executed rows according to 
25 the input signal information received by the logic cone input tracing section 63 and the 
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correspondence information that represents the correspondence between the combinations 
of input signals to the logic cone in the emulation execution section 54 and the executed 
rows which has been extracted by the logic cone input-executed row correspondence table 
creating section 61,. 

5 The executed-row compilation section 12 counts the number of times of 

execution for each row based on the executed-row information extracted from the 
executed-row analyzing section 23 and outputs a coverage result 6 after the emulation 
execution process is completed. 

Next, a process performed in the logic cone input-executed row 
10 correspondence table creating section 61 is described with reference to FIG. 22. 

In the first place, the emulation apparatus reads the RTL description 1 
(ST601). Herein, it is assumed that the emulation apparatus reads the RTL description 
shown in FIG. 3A. 

Then, the logic cone input-executed row correspondence table creating 
15 section 61 reads the logic cone RTL-Gate correspondence information 60 (ST602). 

Then, the RTL description 1 read at step ST601 is divided among the 
respective logic cones (ST603). In the case of the RTL description 1 of FIG. 3A, a group 
of the 100th to 1 15th rows corresponds to a single logic cone. 

The process of a logic cone-specific correspondence table creation loop of 
20 subsequent steps ST604 to ST611 is performed on every logic cone obtained at 
step ST603. 

Then, input signals to a logic cone that is to be processed are extracted 
(ST605). In the case of the RTL description 1 of FIG. 3A, the input signals to the logic 
cone are "a" and "b". 

25 Then, signals for use in the emulation execution section 54, which 
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correspond to the input signals to the logic cone extracted at step ST605, are extracted 
(ST606). Hereinafter, the signals for use in the emulation execution section 54 which 
correspond to the logic cone input signals are referred to as "logic cone gate level block 
inputs". 

The process of a logic cone input pattern generation loop of subsequent 
steps ST607 to ST610 is performed on all of the combinations of input signals to the logic 
cone extracted at step ST605. In the case of the RTL description 1 of FIG. 3A, the process 
of the logic cone input pattern generation loop is performed on 4 combinations of 
{a, b}={Wl, W2}={0,0}to{l, 1}. 

Then, executed rows of a target logic cone for a target combination pattern 
are analyzed (ST608). In the case where the target pattern is {a, b}={Wl, W2}={0, 0}, the 
executed rows are the 100th, 101st, 102nd, 1 13th and 114th rows. 

Then, the correspondence between the gate level logic cone inputs and the 
executed rows, which has been obtained at step ST608, is added to the logic cone input- 
executed row correspondence table (ST609). 

Then, the combination of the input signals to the logic cone is changed, and 
the process returns to the loop of steps ST607 to ST610. After all of the combinations 
have been processed, the process proceeds to a next logic cone, and the loop of 
steps ST604 to ST611 is performed. FIG. 23 shows a logic cone input-executed row 
correspondence table obtained by performing the above process on the RTL description 1 
shown in FIG. 3A. 

Next, a process performed in the executed -row counting section 62 is 
described with reference to FIG. 24. 

The executed-row counting process is started at the same time with the start 
of the emulation execution process (ST650). 
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Then, the gate level logic cone inputs to each of the logic cones obtained in 
the logic cone input-executed row correspondence table creating section 61 are registered 
as a trace point used in the emulation execution process (ST651). 

The executed-row counting loop of subsequent steps ST652 to ST656 is 
5 continued till the emulation execution process is completed. 

Then, it is checked whether or not the trace point has been changed in the 
emulation execution process (ST653). The above-described process up to step ST653 is 
performed in the logic cone input tracing section 63. 

If the trace point has not been changed at step ST653, the process returns to 
10 the loop that starts from step ST652. If the trace point has been changed, the executed 
rows are extracted according to the value of the changed trace point and the logic cone 
input-executed row correspondence table obtained from the logic cone input-executed row 
correspondence table creating section 61 (ST654). This process is executed in the 
executed-row analyzing section 23. 
15 Then, the executed-row summation tables for all of the executed rows 

extracted at step ST654 are each incremented by 1 (ST655). This process is performed in 
the executed-row compilation section 12. 

Hereinafter, the process returns to the executed-row counting loop that 
starts from step ST652 to repeat the executed-row counting process till the emulation 
20 execution process is completed. 

A coverage result obtained by performing the above-described executed- 
row counting process on the RTL description 1 shown in FIG. 3A and the test vector 2 
shown in FIG. 3B is the same as the coverage result 6 shown in FIG. 4. 

As described above, according to embodiment 6, the input signals to the 
25 logic cone always exist in the gate level netlist 52 even when the optimization process is 
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executed by the logical synthesis section 51. Thus, the coverage can be measured even 
when the optimization process is executed by the logical synthesis section 51. That is, the 
optimization process can be carried out even when the coverage is measured. Therefore, 
the emulation method of embodiment 6 is applicable to a circuit of a larger scale as 
5 compared with the emulation method of embodiment 5. Furthermore, the speed of the 
emulation process is increased. 



(Embodiment 7) 

In the simulation apparatuses of embodiments 2-4, the block input-executed 

10 row correspondence table creating section 20 deals with input signals to each description 
block on a bit-by-bit basis. Thus, as the number of the input signals to the description 
block is increased, the number of all the combinations of the input signals is accordingly 
increased to an enormous number which cannot be dealt with. An objective of 
embodiment 7 is to achieve coverage measurement of a description block which receives 

15 many input signals in a simulation of a hardware description language. 

FIG. 25 shows a structure of a simulation apparatus according to 
embodiment 7. This simulation apparatus includes a simulation execution section 3, a 
condition-specific block input-executed row correspondence table creating section 70 and 
an executed row counting section 71. 

20 The condition-specific block input-executed row correspondence table 

creating section 70 divides a RTL description 1 into description blocks and analyzes, for 
each description block, the correspondence between the conditions for input signals to the 
block and the executed rows, thereby extracting correspondence information that 
represents the correspondence between the conditions for input signals to the block and the 

25 executed rows. In the condition-specific block input-executed row correspondence table 
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creating section 70, the execution condition for each row is analyzed, and the input signals 
to the block are dealt with on a condition-by-condition basis, whereas in the block input- 
executed row correspondence table creating section 20 of embodiments 2-4 the input 
signals to the block are dealt with on a bit-by-bit basis. 
5 The executed row counting section 71 includes a block input tracing 

section 22, a condition-specific executed row analyzing section 72 and the executed-row 
compilation section 12. 

The block input tracing section 22 receives from the simulation execution 
section 3 input signal information every time any input signal to the description block 
10 obtained by the condition-specific block input-executed row correspondence table creating 
section 70 is changed. 

The condition-specific executed row analyzing section 72 extracts executed 
rows according to the input signal information received by the block input tracing 
section 22 and the correspondence information that represents the correspondence between 
1 5 the input conditions for the block and the executed rows which has been extracted by the 
condition-specific block input-executed row correspondence table creating section 70. 

The executed-row compilation section 12 counts the number of times of 
execution for each row based on the executed-row information extracted from the 
executed-row analyzing section 23 and outputs a coverage result 6 after the simulation 
20 execution process is completed. 

Next, a process performed in the condition-specific block input-executed 
row correspondence table creating section 70 is described with reference to FIG. 26. 

In the first place, the simulation apparatus reads the RTL description 1 
(ST701). Herein, it is assumed that the simulation apparatus reads the RTL description 1 
25 shown in FIG. 27. 
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Then, the read RTL description 1 is divided into description blocks 
(ST702). Through this process, the read RTL description 1 is divided into the description 
block of the 300th to 304th rows and the description block of the 306th to 308th rows (see 
FIG. 27). 

5 The process of a block-specific correspondence table creation loop of 

subsequent steps ST703 to ST710 is performed on all of the description blocks which are 
obtained at step ST702. Furthermore, the execution condition analyzing loop of 
steps ST704 to ST709 is repeated till the analysis for all the rows of a description block to 
be processed is completed. 
10 Then, the execution condition for an executed row to be processed is 

analyzed (ST705). 

Then, it is checked whether or not the execution condition extracted at 
step ST705 exists in the condition-specific block input-executed row correspondence table 
(ST706). If it exists, a currently processed row is added as an executed row to the 
15 execution condition in the condition-specific block input-executed row correspondence 
table (ST707). If it does not exits in the condition-specific block input-executed row 
correspondence table at step ST706, the execution condition and the executed row are 
added to the condition-specific block input-executed row correspondence table (ST708). 

After the rows of all description blocks have been processed (ST709), the 
20 target block is switched to a next description block (ST710), and the process returns to the 
block-specific correspondence table creation loop that starts from step ST703. 

FIG. 28 shows a condition-specific block input-executed row 
correspondence table which is obtained when the above process is performed on the RTL 
description 1 of FIG. 27. 
25 Next, a process performed in the executed row counting section 71 is 
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described with reference to FIG. 29. 

The executed-row counting process is started at the same time with the start 
of the simulation execution process (ST750). 

Then, the input signals to each block which are obtained in the condition- 
5 specific block input-executed row correspondence table creating section 70 are registered 
as a trace point used in the simulation execution process (ST751). 

The executed-row counting loop of subsequent steps ST752 to ST756 is 
continued till the simulation execution process is completed. 

Then, it is checked whether or not the trace point has been changed in the 
10 simulation execution process (ST753). The above-described process up to step ST753 is 
performed in the block input tracing section 22. 

If the trace point has not been changed at step ST753, the process returns to 
the loop that starts from step ST752. If the trace point has been changed, executed rows 
corresponding to an interested condition are extracted according to the value of the trace 
15 point and the condition-specific block input-executed row correspondence table obtained 
from the condition-specific block input-executed row correspondence table creating 
section 70 (ST754). This process is executed in the condition-specific executed row 
analyzing section 72. 

Then, the executed-row summation tables for all of the executed rows 
20 extracted at step ST754 are each incremented by 1 (ST755). This process is performed in 
the executed-row compilation section 12. 

After step ST755, the process returns to the executed-row counting loop that 
starts from step ST752 to repeat the executed-row counting process till the simulation 
execution process is completed. 
25 FIG. 31 shows a coverage result 6 obtained by performing the above- 
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described executed-row counting process on the RTL description 1 shown in FIG. 28 and a 
test vector 2 shown in FIG. 30. 

In embodiment 7, the process of preventing an error count in the coverage is 
not carried out. Thus, the coverage result 6 (FIG. 31) includes an error count. However, if 
the process of preventing an error count in the coverage which has been described in 
embodiments 3 and 4 is employed, a correct coverage result which has no error count is 
obtained. 

In embodiment 7, the condition-specific block input-executed row 
correspondence table creating section 70 establishes the correspondence between the input 
conditions and the executed rows for each execution condition of each row of the 
description block on a execution-condition by execution-condition basis, whereas in 
embodiments 2-4 the correspondence between the description block inputs and the 
executed rows is established on a bit-by-bit basis. Thus, according to embodiment 7, the 
coverage measurement can be performed on a description block which receives many input 
signals. 
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